C Standard

  • A specification.

  • “Standard C” = features defined in the ISO C specification.

  • It never provides code for the library. The goal of the standard is portability of behavior, not uniformity of implementation.

  • It defines two things:

    • The language rules :

      • syntax, semantics, types, etc.

    • The required library interface :

      • headers, functions, macros, their specified behavior

  • C runs on everything from microcontrollers to supercomputers.

  • Implementations need hardware-specific optimizations (e.g., using vector instructions or memory-aligned stores).

  • The standard only mandates what must happen, not how.

  • The C language  defines a portable abstract machine .

  • The C standard library  defines a portable API  to that abstract machine.

  • What’s “standard” is not what a machine supports, but what all conforming C environments  must make available.

  • Real hardware differs wildly—word size, endianness, memory model, I/O systems.

  • C’s purpose is to let code compile and behave the same way across all that.

  • The C standard library is small compared to the standard libraries of some other languages. The C library provides a basic set of mathematical functions, string manipulation, type conversions, and file and console-based I/O. It does not include a standard set of "container types" like the C++ Standard Template Library, let alone the complete graphical user interface (GUI) toolkits, networking tools, and profusion of other functionality that Java and the .NET Framework provide as standard. The main advantage of the small standard library is that providing a working ISO C environment is much easier than it is with other languages, and consequently porting C to a new platform is comparatively easy.

Libraries from the C Standard specification

Headers

  • Table of all the headers .

  • Anything not listed there (e.g. <conio.h> , <unistd.h> , <pthread.h> , filesystems, sockets, threads, graphics) is implementation-specific, not covered by the C standard; it is intentionally left to external or platform libraries (POSIX, Win32, etc.).

  • “Implementation extensions” = compiler or OS additions beyond it.

Why these topics?

  • This topics were chosen to define a minimal and portable core, enough to write complete programs on any system without assuming specific hardware or OS features.

  • The C committee’s logic:

    • Include only functionality that every environment can realistically support (memory manipulation, text handling, math, time).

    • Exclude features that depend on an operating system, filesystem layout, or hardware model (threads, graphics, networking).

    • Keep the language lightweight so it can run on bare metal as well as general-purpose systems.

    • The aim was universality, not completeness.

Opinions

Good

  • It provides a portable contract : if you stick to standard headers and functions (e.g., from The C Programming Language or the ISO/IEC spec), you get behavior that works across many platforms.

  • It keeps the “core” relatively small (at least compared to many modern high-level libraries), so you get low-level control, minimal runtime overhead.

  • Because implementation is deferred (you don’t get code in the spec), libraries can be optimized per hardware/OS, which makes C usable in embedded, OS, and systems-programming domains.

Problems

Buffer overflow vulnerabilities

  • Some functions in the C standard library have been notorious for having buffer overflow vulnerabilities and generally encouraging buggy programming ever since their adoption.

  • The most criticized items are:

    • string-manipulation routines, including strcpy()  and strcat() , for lack of bounds checking and possible buffer overflows if the bounds are not checked manually;

    • string routines in general, for side-effects "Side effect (computer science)"), encouraging irresponsible buffer usage, not always guaranteeing valid null-terminated output, linear length calculation;

    • printf()  family of routines, for spoiling the execution stack when the format string does not match the arguments given. This fundamental flaw created an entire class of attacks: format string attacks;

    • gets()  and scanf()  family of I/O routines, for lack of (either any or easy) input length checking.

  • Except the extreme case with gets() , all the security vulnerabilities can be avoided by introducing auxiliary code to perform memory management, bounds checking, input checking, etc. This is often done in the form of wrappers that make standard library functions safer and easier to use.

  • C11 seems to improve on that a bit.

Threading problems, vulnerability to race conditions

The strerror()  routine is criticized for being thread unsafe and otherwise vulnerable to race conditions.

Error handling

  • The error handling of the functions in the C standard library is not consistent and sometimes confusing. According to the Linux manual page math_error , "The current (version 2.8) situation under glibc is messy. Most (but not all) functions raise exceptions on errors. Some also set errno . A few functions set errno , but do not raise an exception. A very few functions do neither.

Critiques

  • Some researchers question how standards are set: choices may be influenced by consensus, legacy, politics, rather than purely technical optimality.

  • Because C supports so many platforms (embedded, low-resource, large servers), the library must compromise between extremes — meaning “what you get” may not be ideal for your  domain (e.g., game dev, safety critical, high-perf).

Versions

C89/C90

  • Original ANSI/ISO C standard.

C99

  • Added inline , //  comments, variable-length arrays, and more standard headers.

C11

  • Introduced multithreading ( <threads.h> ), _Atomic , and optional bounds checking.

  • C11 .

C17

  • Bug-fix revision of C11, no major new features.

C23

  • Adds UTF-8 literals, improved enums, and more modern conveniences.